With the advent of intelligent networks, the number of calling features, such as “call waiting” and “call forward busy,” have greatly increased. These features are triggered based on a defined event during a telephony call. Since multiple features may be available for a given event, the order in which these features are initiated is defined in a feature queue. Thus, when the trigger event occurs, the entity providing call processing will attempt to initiate the features in the feature queue in a sequential fashion.
Typically, the events, features, and order of the features in the feature queues are set for an entire switching center, such as a central office or mobile switching center. In addition, both the telephony equipment manufacturers and the service providers are typically constrained by the event and feature policies established by standards entities, such as Bellcore. At the present, these entities define the events that trigger features and the order in which these features are initiated for a given event. When customers of the equipment manufacturers want to modify the event and feature policies dictated by the standards entity, the equipment manufacturer, customer, and standards entity must get together and negotiate any changes in the policies, because the equipment manufacturers cannot unilaterally change the policies. Although the customers could theoretically change their individual event and feature policies, there is not way to facilitate the modification of events and features at a per-office level. As such, there is a need for a way to modify call processing events and feature initiation sequences on a per-office basis.
Further, many subscribers and groups of subscribers may not subscribe to the services associated with the call features. For example, many subscribers and groups thereof do not subscribe to call waiting and an even greater number typically do not subscribe to call forward busy services. Unfortunately, the rigid structure of the current call processing architecture attempts to initiate each of these features, even if the subscriber or group thereof does not subscribe to the service associated with the feature. Given the numerous events and potential features for each of these events, a significant amount of processing time and power is wasted attempting to initiate features that are not relevant to the given call. As such, there is a need for a way to eliminate unnecessary attempts to initiate call features that are not available for a subscriber, group of subscribers, or office.
A further failing of the existing call processing architecture is the inability to change the order of initiation of features for a given event. For example, if a subscriber or group of subscribers subscribe to call waiting and call forward busy services, many of the subscribers may want to have the call waiting service initiated prior to call forward busy whereas others would rather the call forward busy service initiate prior to call waiting. Similar decisions may be desired for an entire office. Regardless of whether it is the entire office, a group or subscribers, or an individual subscriber, there is a need to provide an efficient way to select the order in which features are initiated for a given event in addition to defining features for a given event.